Visier Security Model

Learn more about Visier's permission-based security model and how access to historical data is handled.

Overview

Visier uses a permission-based security model, as shown in the illustration below. Each permission contains data security configurations, capability settings, and content packages. Data security consists of security filters and data access sets, which determine what data users can see in the solution. Security filters define what population users can access (for example, Employees) and data access sets define what properties the user can access for that population (for example, Birth Date and Job Name). Capabilities define the actions users can perform in the solution. Content packages define the content a user can see in the solution. You have control over the analyses that are in guidebooks and the metrics, dimensions, and key groups that users can use to conduct ad hoc analysis in Explore. Capabilities and content packages are not part of data security because you're not restricting access to data. You are only limiting the actions and content that users have. For more information, see Permission Management.

Tip: To learn more, take the Visier University eLearning course: Building your security model.

How Visier security handles access to historical and future data

Dimension members such as departments, and subject members such as individual employees, have states that change over time. Historical and future data capture these changing states in order to provide insights into organizational shifts and span of control.

When data is loaded for each subject, it is given a start date and an end date. Historical data is any information that was recorded on or prior to the end date of the subject’s loaded data, whereas future data is any information that was recorded after the end date of the subject’s loaded data.

By default, you will gain access to the historical and future data of members who are in your security context. Your access extends to related members, even those who are not included in your current security context. You will also gain access to any members who are scheduled to move into your security context in the future.

Historical data

Under Visier’s security model, if you have access to a member, you can see the historical data of that member and any related members.

Organizational hierarchies change over time, as shown in the following illustration, where Bob transfers teams and reports to a new manager in 2016.

Let's say you have detailed access to Anthony's team. Through this security context, you get access to Bob and his historical data up until the subject end date in December 2016. A member's historical data is often intertwined with the history of other related members. In this example, Bob was a manager on his previous team. In order to accurately understand Bob as a manager and preserve the history of the organization structure, you would need access to the historical data of Bob's reports.

If you were to look into Bob’s span of control in 2015, you would see Charlie, Dave, and Edward. Although they never reported to Anthony, and are not included in your security context, you get access to their historical data because they are part of Bob's history.

You gain access to the historical data of the related members when they are included in the history of an accessible member. You will get access to Charlie, Dave, and Edward for the period of time that they reported to Bob, meaning your access to them only extends to 2016, up until Bob transferred to the new team.

Restrict user access to historical data

Note:

Limited Availability This feature is in limited availability. If you are interested, please contact your Partner Success Manager.
You may experience performance issues when Advanced Historical Analysis is enabled.
If your organization uses a feature called Apply Security as Filters, you may encounter unexpected behavior associated with historical data. This is because if a security filter is applied, it disables Advanced Historical Analysis and may cause discrepancies in your data. If there aren’t any security filters applied then Advanced Historical Analysis will work as expected.

By default, all users are able to access historical data in Visier as described above. Optionally, your organization can enable Advanced Historical Analysis, a feature that allows administrators to limit which users get access to historical data of related members through a permission capability. For more information on the Advanced Historical Analysis capability, see Capabilities List.

You may want to enable the Advanced Historical Analysis feature in your solution if:

You want your users to analyze data relevant to the populations they can access. This feature restricts the user from seeing historical data about any members outside of their current population access.
You want to allow a limited number of users to analyze historical data. At your discretion, you can decide which users in your organization can do advanced analysis of the organization's populations with access to related member’s historical data across time.

The following diagram illustrates user access to historical data of related members by whether or not the Advanced Historical Analysis feature is enabled.

Let’s say your organization enabled Advanced Historical Analysis but did not assign you that capability. Without the Advanced Historical Analysis capability, you can only view data related to the populations that you have permission to access.

Using the previous example, when you look at Bob’s span of control in 2015, you will not get access to related members. You will see Bob listed under Andrew’s team in 2015, but you will not be able to view the historical data of Charlie, Dave, or Edward because they are not included in your population access.

Future data

Under Visier’s security model, if a member has future data attached to them and they will be moving into your security context, you will gain access to their data.

Continuing with the previous example, let’s say that in 2016, a member named Jan joins Andrew’s team and reports directly to Andrew. Soon after she joins Andrew’s team, she is scheduled to move to Anthony’s team in 2017. The subject end date is December 2016, therefore Jan's move is future data.

Although Jan is not currently part of Anthony’s team, anyone with population access to Anthony’s team will get access to Jan’s historical data once the transfer is attached to her employee record. Until the transfer happens in 2017, anyone with population access to both Anthony and Andrew’s teams will have access to Jan’s current and historical data. After Jan moves to Anthony’s team, she is no longer part of Andrew’s population access. Anyone with access to Andrew’s team will lose access to Jan after 2017, which is the latest time she was part of the included population.